전병선이라는 대단한 사람이 살고 있었습니다.
그 사람이 몇마디를 했습니다.
아래로...
--------------------------------------------------------------------------------
최근 한국 마이크로소프트의 MSDN 온라인 사이트 (http://www.microsoft.com/korea/msdn/default.asp) 에 들어가면 빨간색으로 강조된 타이틀 하나가 눈에 확 들어옵니다.
최근 벤치마크에서 .NET 기술로 개발한 Pet Shop 이 J2EE 기술로 개발한 Pet Store 에 비해 최대 331% 라는 놀라운 성능을 입증하였다는 것이지요.
이로써 .NET 대 J2EE 사이의 2차 대전이 발발했습니다.
그것도 자바 기술 진영의 커뮤니티인 TheServerSide.com 에서 이런 발표를 했으니, 보나마나 .NET 진영은 신이 나서 침 튀기면 마구 떠들어대고 있고 J2EE 진영에서는 한숨을 푹푹 내쉬고 있을 겝니다.
내가 이 기사를 시작으로 한 것은 '그러니까 .NET 이 더 낫다' 고 말하려고 하는 것을 절대로 아닙니다. 내가 생각하기에 이들 두 기술들이 이렇게 서로 잘났다고 싸우고 있지만, 사실은 뭐 서로 다를 바가 없다는 것이지요. 그것은 이 두 기술들이 이처럼 라이벌로서 서로 경쟁하며 발전하고 있는 과정에 있기 때문이지요.
아직은 어느 하나가 완승을 거둘 만큼은 아닌 것 같습니다.
그래도 이렇게 두 진영의 업체에서 서로 싸우는 것은 이해가 가는 일입니다.
이들 업체의 입장에서 보면 이 싸움에서 이겨야 그래도 커다란 밥그릇을 가질 수 있을테니까 말이죠. 결국 밥그릇 싸움이란 얘기죠.
그런데 문제는 개발자나 학생들이 이 싸움에 끼어들어서 '똥이다 된장이다' 한다는 것입니다.
차라리 그 싸움에 시간을 낭비하기 보다는, 상대방의 기술을 받아들여 내 것으로 소화하는 것이 더 낫지 않나 싶습니다.
제 경우도 CORBA 나 EJB 기술을 공부하면서 COM/COM+ 기술을 더 확실히 이해하게 되었으니까요. 그 반대로 COM/COM+ 기술을 이해하면 CORBA 나 EJB 를 이해하기 쉬울 것입니다.
특히 마이크로소프트의 기술에 익숙해져 있는 개발자들이라면 열린 마음으로 한번쯤은 자바 기술을 받아들여야 할 필요가 있습니다.
적어도 우물 안의 개구리가 되기 싫다면 말이죠.

언젠가 데브피아 게시판에 이런 내용의 글이 올라왔습니다.
요약하면 이렇습니다. string test = "테스트입니다요...~~~테스트입니다요...~~테스트입니다요." ;
int i;
for(i=0;i<50;i++)
{
test = test + test ;
}

이 소스 코드가 100 MB 이상의 많은 메모리를 잡아먹는다는 것이지요.
한번 해보라는 군요.그리고 자신의 의견을 남겨놓았습니다.
'JIT문제인것 같습니다만 정식 버전의 안정성이 의심되는군요..
이 글에 대해 '정말 그렇다', '이상이 아니다' 열심히 논쟁이 붙었습니다.
그 와중에 정말 명쾌한 답이 있었습니다. 요약하면 이렇습니다.

String 클래스는 Immutable 패턴에 따라 구현되었기 때문에 위의 테스트 코드에서는 String 클래스를 사용하면 안된다는 것이지요. 테스트 코드의 목적에 적합한 클래스는 String 이 아니라 StringBuffer 라는 겁니다. 그리고 Immutable 패턴에 대해 자세한 설명을 덧붙였습니다.
정말로 좋은 내용의 글입니다만 지면 관계로 내용을 옮기지 못하겠군요.
데브피아 게시판에서 String 을 검색해보면 찾을 수 있을 겁니다.

사실 이러한 일은 얼마든지 있을 수 있습니다. 그런데 문제는 마이크로소프트 기술을 공부하는 개발자들이 디자인 패턴(design pattern)이라고 하는 것에 익숙하지 못하다는 것이지요.
이와 더불어, 프레임워크(framework) 이나 아키텍처(architecture) 와 같은 용어에도 익숙하지 않습니다.
물론 닷넷 프레임워크 라든가 MFC 의 애플리케이션 프레임워크(application framework), 그리고 Windows DNA 아키텍처 라는 용어는 많이 들어봤을 것입니다.
또 Windows DNA 아키텍처가 MVC 패턴을 적용하고 있다는 이야기도 들었을 것입니다. 그런데 이들 용어에 대해 어느 정도 제대로 이해하고 있는 사람들은 별로 없습니다.
그러나 재미있는 것은 자바 기술을 공부하다보면 이런 용어들에 쉽게 익숙해진다는 것이지요. 설사 그 용어의 의미를 완전히 이해하지는 못하더라도 말이죠.
사실 이들 용어에 대한 정확한 정의에 대해서는 학자들 사이에서도 의견이 분분하니까 정확하게 이해한다는 것은 어려운 일일 것입니다.

아무튼 만약 앞의 예에서 문제를 제기했던 사람이 자바를 공부했더라면, 그래서 디자인 패턴에 익숙해있었더라면 (물론, 자바를 공부했다고 해서 모두 다 디자인 패턴을 잘 아는 것은 아니겠지만) 좋았을 뻔 했다는 생각이 듭니다.
그렇다고 절대로 .NET 개발자가 자바 개발자 보다 실력이 없다고 하는 것은 결코 아닙니다.
절대로 오해하지 마세요.
자바 개발자도 .NET 개발자에게서 배워야 할 것들이 많답니다.
다소 인위적이기는 하지만, 자바 기술이 어느 정도 학술적인 성격을 띠고 있다면, 마이크로소프트의 기술은 실용적이라고 할 수 있습니다.
아마도 대학이나 연구 기관에서 자바 기술을 선호하는 가장 큰 이유가 이 때문이 아닌가 생각됩니다.
실상 대학에서 아키텍처나 프레임워크, 디자인 패턴 등을 학생들에게 가르치려 할 때 마이크로소프트 기술 쪽에서는 적당한 자료를 찾기 힘들다는 이야기를 듭습니다. 그러나 막상 이들 기술을 시스템에 적용하려고 하면 자바 기술로는 표현하기 어려운 것들이 있는 것이지요.
결국 이 두 기술을 모두 이해하고 있다면 이론적이든 실용적이든 모두 이해하고, 이들 기술의 장단점을 잘 살려서 우리가 원하는 효율적인 시스템을 구현할 수 있게 된다고 할 수 있습니다.

이 첫번째 컬럼에서 제가 개발자 여러분들에게 이야기하고 싶은 것은
"열린 마음으로 서로를 바라보고 이해해야 한다"는 것입니다.
그것이 결국 여러분 스스로에게도 커다란 도움이 되기 때문이지요.